Software Vault: The Diamond Collection

home *** CD-ROM | disk | FTP | other *** search

/ Software Vault: The Diamond Collection / The Diamond Collection (Software Vault)(Digital Impact).ISO / cdr38 / bcheck13.zip / BCHECK13.DOC < prev next >

Wrap

Text File | 1995-03-05 | 45KB | 883 lines

BCHECKERS | | version 1.3 | | | A multi-node checkers door for most BBS systems | Copyright 1995 by DIRT CHEAP SOFTWARE | Written in C by Bruce Bowman | | Released January ?, 1995 | | INTRODUCTION ------------ -------------------------------------------------------------------------- | >Disclaimer< Throughout this document, I have used the masculine gender | | when referring to a "generic" person. This is only to avoid continuous | | use of such things as (s)he, which I find annoying. I have total respect | | for the females of the species; I even married one. So lighten up. :^) | | -------------------------------------------------------------------- | | >Disclaimer #2< The author of this program, Bruce Bowman, promises only | | that this program will take up space on your hard drive (and perhaps not | | even that). I've put a lot of my time and sweat equity into this, and in | | return I ask only that you try it and remit a token sum if you continue | | to do so. I make no claims for its suitability for a particular purpose, | | and guarantee nothing whatsoever regarding potential damage to your own | | computer or hard-acquired files. I can only suggest that you do what I | | do, and back up your hard drive frequently. If the unthinkable happens | | and some terrible fate should befall you as a direct or indirect result | | of using BCheckers, you will have my utmost sympathy -- but that's about | | all. So there. :^) | | -------------------- | | This software is copyrighted: You're subject to the associated penalties | | of law if you attempt to reverse-engineer it, hack the key routines, or | | otherwise steal the benefits of all my aforementioned sweat equity. | -------------------------------------------------------------------------- As a sysop of a FidoNet BBS, I was disappointed in the lack of a good, non-interactive checkers door. Sure, there were some that allowed inter- node play and the like, but these were expensive and few offered any decent ANSI graphics and the simple ability to have callers make moves on alternate logons. I also wanted to try my hand at programming in C, having learned a number of other programming languages. BCheckers is the result of this effort; and at only $10 is a bargain in shareware. BCheckers offers the following sysop features (and more I've probably overlooked in these docs): - As you would expect, BCheckers monitors carrier detect functions, to automatically recover when a user drops carrier. - Includes a fully-adjustable inactivity timeout monitor. A warning is sent 5 seconds before the caller is ejected. - Share-aware file i/o for use in multi-node BBS systems. You must have DOS's SHARE.EXE loaded for multi-node use. - Supports most popular BBS door information files, such as DORINFO1.DEF, EXITINFO.BBS, CHAIN.TXT, DOOR.SYS, etc. - Displays and updates a QuickBBS-style status line, with information available to the sysop such as user name, location, baud rate, time left, function keys, ANSI and AVATAR settings, and so on. - Keeps track of a user "wants-chat" indicator, just like the one in RemoteAccess, QuickBBS and other BBS systems. Allows for sysop page from the door, and integrated chat mode. - Provides the sysop with all the standard function keys for adjusting user time, hanging up on or even locking out the user -- and sysop shell to DOS. - Full support for locked baud-rates of up to 115200 baud, using the FOSSIL driver for maximum compatibility with any system. If a FOSSIL is not available, BCheckers will use its own communications routines. Auto-detect of local operation. - BCheckers is also DesqView and Windows aware. It will automatically check for the presence of a multitasker, and if available, will perform all of its screen output through the appropriate function calls. CONVERTING FROM VERSION 1.0 --------------------------- * * IMPORTANT!! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * If you've been running version 1.0 of this program, you MUST execute * * 10TO11.EXE in the BCHECK directory prior to running version 1.1 or * * any later version of BCHECKERS!! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The data file BCHECK.BBS in versions after 1.0 now hold the players' comments to each other and a draw-request indicator. Each record is 78 bytes longer than in version 1.0. If you run later versions without running 10TO11.EXE, you will corrupt your BCHECK.BBS file and lose all games in progress. Your callers probably won't appreciate this! To upgrade, overwrite your old copy of BCHECK.EXE with the new version. Copy the 10TO11.EXE file to the directory containing your BCHECK.BBS file. Close any tasks that might access the BCHECK program, then type the following at the DOS prompt: 10TO11 This will update the BCHECK.BBS file to the new format. Once completed, you may delete the 10TO11.EXE program. If you don't mind losing all your games, just delete the BCHECK.BBS file from the DOS prompt. IF YOU'RE NOT RUNNING VERSION 1.0, YOU DO *NOT* NEED TO USE 10TO11.EXE!! BCHECKERS QUICKSTART ------------------ To get the door up and running when not upgrading, do the following... 1) Copy the BCHECK.EXE file to the directory from which you plan to run the door. 2) Create a door batch file, similar to the following: CD \BBS\DOORS (location of BCHECK executable) BCHECK <parameters> (see below) CD \BBS EXIT 3) Create a menu entry to call the door. This varies according to your BBS software. I recommend a "spawn" type of door call (e.g.: type 7 on QuickBBS or Remote Access). That's really about all there is to it! Now, you need to know about the command line parameters, so here goes... COMMAND LINE PARAMETERS ----------------------- ** Soapbox mode ON ** One thing that has always irritated me is the number of config files and the like that clutter my directories. I see no need to have an executable, a maintenance program, a config file and program, and a data file for each game (like many door programmers prefer). Although harder to do, I've designed BCheckers so it doesn't need all those files -- all it uses, besides the executable, is two data files (the Hall of Fame and a user activity log). Configuration is done exclusively via command line parameters. ** Soapbox mode OFF ** Call the program with the following syntax. Only the <path> parameter is required. Parameters indicated with an asterisk (*) can only be configured in the registered version. BCHECK <path> <DtoL> <DtoK*> <MaxGam*> <InAct*> <MaxTim*> <PaOff*> <PaOn*> [ <Baud> <IRQ> <Add> ] Where: <path> REQUIRED: Path to the door drop file(s). This will vary depending on the node using the door. I usually set things up so the node number is passed on the batch file command line, so the door can be called with something like: BCHECK \BBS\NODE%1. That way, you can use the same batch for any number of nodes. You can also force BCheckers to preferentially read a particular drop file by placing its name along with the full path. This is handy if BCheckers is reading one drop file first -- one that doesn't have all the data it needs to run properly. <DtoL> "Days to Lose" - Number of days before an inactive game is aborted. This is the way we keep games from piling up without someone actively playing. If a player does not make a move in a game after this number of days, the last player to move is declared the winner (if there ARE two players -- otherwise the game is simply deleted). Default value is 21 days (3 weeks). If you choose to use this default but want to specify a value for one of the subsequent parameters, insert XX (or any other string of *non-numeric* characters) as a placeholder. All this really does is make sure the help screens give the correct value to your callers -- check out the "maintenance" section later in this document. <DtoK*> "Days to Keep" - Number of days a completed game is held before being purged from the game file. This allows a few days for the players and other callers to see the outcome. Treat this just as you would the DtoL parameter. Default is 10 days. <MaxGam*> Maximum number of games an individual can play at once. Default value is 5, acceptable range is 1-200. A value of zero is ignored, giving the default. Again, insert a placeholder if you want to specify a value for any subsequent parameters. <InAct*> Time, in seconds, before a user is returned to the BBS for inactivity. If your caller goes to sleep at the terminal, this will bump him off and back to the board. Keep this number high enough that the caller has enough time to think about what move he wants to make. Default is 200 seconds. <MaxTim*> Maximum time, in minutes, you will allow a caller to spend in the door. Default is the total amount of connect time available to the caller (ie: no restriction). A warning is sent shortly before the caller runs out of time. <PaOff*> Time, in minutes after midnight, for paging hours to end. Valid numbers are 0-1440. By default, paging is always on; so if you enter an invalid number, that's what you'll get. <PaOn*> Time, in minutes since midnight, for paging hours to resume. If you *never* want a caller to page you, enter a value of exactly midnight (zero) for PageOn, or simply don't provide a value for PageOn at all. USE THE FOLLOWING PARAMETERS ONLY IF YOU DO NOT USE A FOSSIL FOR MODEM I/O! Using any of these parameters disables use of the FOSSIL. In most cases, it is better to set one or more of these values on your FOSSIL command line and just use the FOSSIL for i/o -- but if your BBS software does not require a FOSSIL, or for some reason you prefer the FOSSIL not be used, you can still run the door using these parameters and BCheckers's internal comm routines. <Baud> The computer-to-modem data transfer rate (DTE speed). THIS IS NOT THE MODEM-TO-MODEM CONNECT SPEED. This value must evenly divide 115200 (115200, 57600, 38400, 28800, 23040, 19200, 14400, etc). Do not use a comma (ie: do not enter the value as 57,600 -- it won't work). If all you want to do is force BCheckers to use its comm routines, you can again put XX or any other non-numeric placeholder string in this position. If you use hardware data compression on your modem (V.42bis or others), I suggest using a value of 4x your highest connect speed to avoid losing characters. For example, for a 9600 baud modem with V.42bis, I recommend using 38400 here. <IRQ> Sets the IRQ line to be used by your modem. Normally, BCheckers will determine the standard IRQ line used by COM1-COM4. If you use a non-standard IRQ line for your modem (usually to avoid a conflict with another device) place its value here. <Add> Base address (in hex). BCheckers can normally determine the base address of the port for you. However, if you prefer to change the base address, place its value here. MAKE SURE IT IS CORRECT!! If it isn't, BCheckers will still dutifully follow your instructions and perhaps overwrite important areas of memory. If you don't understand any of this, DO NOT put ANYTHING here. Standard base addresses and IRQs follow. These are the values that will be used based on the COM port passed in the BBS drop files, unless remapped by your FOSSIL or on the BCheckers command line: COM1 03F8h and IRQ4 COM2 02F8h and IRQ3 COM3 03E8h and IRQ4 COM4 02E8h and IRQ3 Examples: BCHECK \BBS\NODE1 Bring up the door with the drop file located in the \BBS\NODE1 directory. All other parameters take their default values. BCHECK \BBS\NODE2 30 XX XX 300 30 Run the door from node 2. Thirty days before declaring a winner due to inactivity. Use the default value for days to keep and games per player (10 days and 5 games, respectively). Increase the inactivity timeout to 300 seconds, and allow no more than 30 minutes in the door. BCHECK \BBS\NODE1 15 Same as the first example, but keep games for only 15 days before declaring a winner due to inactivity. BCHECK XX 20 ERROR. Path to the drop file is REQUIRED. This will assume the drop file is located in the XX directory, which is probably not what you wanted. BCHECK \BBS\NODE1 XX XX XX XX XX 1260 420 Run BCheckers with the defaults, except disable sysop paging at 9 p.m. and resume at 7 a.m. BCHECK \BBS\NODE3 XX XX 8 XX XX XX XX XX Run BCheckers, forcing use of internal comm routines (assuming a FOSSIL is not available). Callers will be allowed to play no more than 8 games each. BCHECK\BBS\NODE%1 XX XX XX XX XX XX 115200 7 02E8 Run BCheckers using the internal comm routines and non-standard modem settings indicated. The node passed on the batch file command line is using the door. SYSOP FUNCTIONS --------------- Status Line - By default, the status line is OFF. To turn it on, press F10. The status line lists the name of the user currently on-line, his location, and baud rate (0 if the door is operating in local mode). You may also find out how much time the user has left, check for indicators as to whether the user has ANSI and/or AVATAR modes on, etc. If the user wishes to Chat with the sysop (ie: they have paged the sysop, but haven't received a response), a [Want-Chat] indicator will flash on the status line. [F1]..[F10] - The Function keys [F1] thru [F10] allows the sysop access to various types of information on the status line, or to turn the status line off. These keys are as follows: [F1] - Display basic door and user information [F2] - Display phone numbers and important dates [F3] - Display security flags and up/download info [F4] - Display system information and current time [F5] - Display message info and user's settings [F6] - Display chat reason and sysop's comment [F9] - Display help information for sysop [F10] - Toggle the status line on/off In normal usage, the screen will often scroll one line when it attempts to print on a line that is "under" the status line. I REPEAT -- THIS IS NORMAL. Everything looks fine from remote. Keep the status line off when playing in local mode. The following other function keys are also available to the sysop: [UP]/[DOWN] - Use the arrow keys to increase or decrease the amount of time the caller has left in the door. [Alt]-[C] - Allows the sysop to break into chat with the caller at any time. [Alt]-[C] again, or [ESC] will end chat mode. (Notice that the Want-Chat indicator will also be turned off, if it was flashing). If your door is running under Apex, Remote Access or QuickBBS, paging from within the door will also cause the Want-Chat indicator to stay lit when the user returns to the BBS. [Alt]-[J] - Allows the sysop to shell to DOS, if enough memory is available. Simply type EXIT to return to the door. [Alt]-[H] - Hang up on the user. Drops carrier and returns to the BBS. [Alt]-[L] - This key locks the user out of the BBS. It first hangs up on the user, and then sets their security level to 0, to prevent them from ever logging on again. This feature may require use of the EXITINFO.BBS file, depending on what system the door is running under. [Alt]-[K] - The "User Keyboard-Off" key allows the sysop to temporarily prevent the user from typing anything on their keyboard. This has no effect on the local keyboard, but causes the door to ignore any keystrokes from remote. [Alt]-[N] - The "Sysop Next" key, this function reserves the system for use by the sysop after the user logs off, if the door is running under an Apex or RA 1.00 or later system. [Alt]-[D] - "Drop to BBS" key. This function allows the sysop to exit the door and return the user to the BBS, without hanging up. USING THE DOOR -------------- The door is menu-driven, and most of the functions are self-explanatory. A brief overview will be given here. The door is based on the "touch-move" premise. Once a legal piece is chosen, the caller is *required* to move that piece. If only one move is available for the chosen piece, that move will be made immediately -- otherwise, the door will prompt for a destination square by highlighting the legal moves with flashing pieces. Also, the door will not allow the caller to "take back" a move. Thus, it is very important that the caller use due discretion in evaluating the board position *before* they start to make a move. This is not because I am lazy -- the door has been *purposely* programmed this way. Checkers is supposed to be something of an intellectual game, and it is the opinion of this programmer that allowing "take-backs" defeats the purpose of having game doors that are in principle a cerebral challenge between the players. The door conforms to Hoyle's rule for jumps (rather than "Huff or Blow"). If the caller has a capture, he *must* make a capture. If a new game is started, the player is assigned the Black pieces for his first move (in keeping with Checkers conventions). The opponent is "No One" until someone joins the game. The opening screen allows the caller to perform most game operations, as follows: 1) Make a Move -- The caller may make a move in a game in which he is already a player. These games are presented in a list, from which the player chooses the game number. The game selected is then presented to him. If it isn't the caller's move, or the game has been completed, a message to that effect will be displayed. If it is the caller's move, the door will first check if his opponent has offered a draw. If so, he is allowed to accept or reject the offer. If accepted, the game is drawn immediately...otherwise, the offer is discarded and the game proceeds normally. The door then presents the caller with his opponent's message and the following choices: <E>xit -- Abort move selection and return to the game selection menu. <M>ove -- Make a move. The caller will be prompted for a piece to move and a destination square, if required. If the caller selects an illegal move, the door displays an error message and highlights the legal moves. Once a move is made, the door checks for whether the opponent also has a legal move -- if not, the game is won! Otherwise, the caller has the opportunity to either leave a message to his opponent or offer a draw. Up to 75 alphanumeric and punctuation characters may be entered for the opponent to read prior to his next move. If an offer to draw is made, a confirmation prompt is displayed to ensure that the key wasn't hit by mistake. If confirmed, the opponent will be shown the offer and the game will be immediately declared a draw if he accepts. <R>edraw Screen -- Use this if something messes up in data transmission and the screen needs to be cleaned up. <F>orfeit Game -- Use if you want to "give up" and allow your opponent to win. The caller is prompted for confirmation before the game is declared lost. You must have an opponent to forfeit to! 2) View Games in Progress -- Displays any game that has not been deleted. A list of current games is presented to the user so he may select one to view. The board position is then displayed along with status information. 3) Start a New Game -- Same as #1 above, but starts a new game. The caller is always given the Black pieces to start the game. Of course, the <F>orfeit and <D>raw options are not available in this case, since the caller has no opponent yet. 4) Join a Game -- Allows the caller to join a game that someone else started. Having joined the game, the player receives the White pieces, and is given the opportunity to make a move immediately. 5) Checkers Rules and History -- Displays a 3-screen overview of Checkers rules and history. This has been paraphrased from Hoyle. 6) Door Help -- A succinct listing of non-obvious information that should prove useful to first-time users of the door. 7) Page the Sysop -- The sysop can break into chat mode at any time with Alt-C...this command allows the caller to request chat mode. 8) Quit to the BBS -- Exit the door and return to the board. 9) Logoff -- Exit completely, dropping carrier. CARE AND FEEDING OF BCHECKERS --------------------------- **Warning** While you *can* run the MAINT function with the door online, if there are many games or players this may cause a timeout of a user's file access in another task. This won't cause any damage, but it is best to take down all of your BBS nodes prior to running the MAINT function. The other functions do not keep the files open as long, and are thus less likely to cause difficulties -- just make sure you have DOS's SHARE.EXE loaded. Maintenance In order to actually delete old games and declare winners in expired games, the maintenance function should be run daily along with your normal BBS routine. This is accomplished by using the same command line as for normal execution of the program, but replacing the path to the drop file with the string "MAINT". This will go through the game data file and update it as needed. I highly recommend that other parameters used during maintenance be kept the same as you normally use when running the door. If you don't, no real harm will befall you, but your callers may become upset with you once they realize that their help files state the game is deleted after 21 days but the games are actually deleted in 15! Examples: BCHECK MAINT Update the BCHECK.BBS file, using defaults. BCHECK MAINT 30 XX XX 300 30 Use this to perform maintenance on the games data file, using the same parameters as used for running the game (from example 2 displayed previously). Game Deletion If desired, an individual game may be deleted from the command line. This enables you to get rid of games from players like "George Washington," or otherwise deal with twits without adversely affecting the other callers. For example, call the program as follows to delete game #4: BCHECK DELETE 4 **Warning** Do NOT omit the game number on the command line, or the program will delete game number 21 (if it exists). The reasons for this are not particularly important, but in general I feel that if you are going to do this kind of thing, you'd better be on your toes anyway. If the number is higher than the total number of games, or zero or less, a harmless error message is displayed. If you wish to delete *all* the games, simply delete the BCHECK.BBS file at the DOS prompt. The file will be created as needed the next time the door is used. I do not plan anything more elaborate than this for sysop intervention, but will entertain any ideas you may have. Status Bulletin BCheckers will generate a game status bulletin when called with the following syntax: BCHECK STATUS 0|1 The bulletin is sent to StdOut, and can be redirected to a file for display on your BBS; or even redirected to the COM port and run as a separate door! The 0 or 1 indicates whether an ASCII or ANSI bulletin is generated; if omitted, you will get an ASCII bulletin. This bulletin indicates whose move it is in any active game, as follows: BCHECKERS Game Status Game # 1: Jane Doe needs an opponent... Game # 2: Ringo Bowman needs an opponent... Game # 8: John Public to move... Game # 9: Joe Blow to move... [etc...] Press ENTER Completed games do not appear in the bulletin. Note that the bulletin actually begins with an ASCII 12 character (clear screen on most systems) and ends with an ASCII 1 (wait for the ENTER key). Hall of Fame Bulletin BCheckers will read the BCHECK.HOF file and generate a hall of fame bulletin when called with the following syntax: BCHECK FAME 0|1 Like the game status, the bulletin is sent to StdOut, and the 0 or 1 directs the program to generate an ASCII or ANSI bulletin. The bulletin gives player stats as follows: BCHECKERS HALL of FAME Player Wins Losses Draws Percent ------ ---- ------ ----- ------- Richard Hangslough 2 0 0 100 Boz Scaggs 11 2 0 84 Jethro Tull 9 2 3 75 Pink Floyd 10 2 8 70 Howard Johnson 4 2 3 61 Bruce Bowman 7 4 3 60 Fleetwood Mac 2 2 3 50 Press ENTER Up to 18 players will be listed, in order of winning percentage. Draws are treated as 1/2 game won and 1/2 game lost. The percentage is truncated to the nearest percent. REGISTRATION ------------ To Other Shareware Authors: I will happily exchange registrations to any of my products, if what you have interests me at all. Netmail me with the specifics if interested. (Not responsible for lost or misrouted mail!). The key consists of a small file that resides in the same directory as your game file (BCHECK.BBS). Ordinarily, I would find this abhorrent -- but I'm just too stupid to figure out a way to patch the executable with a key entered in a config program (which would also require a config program!). Benefits of Registration ------------------------ 1) The door will only allow configuration of "days to lose", com port parameters, and drop file path until you register. You can go ahead and enter the extra parameters on the command line, but they will be ignored. Most of the defaults are pretty reasonable, though. 2) You cannot disable paging or set paging hours unless registered. 3) The door will only allow up to 12 concurrent games until you register. Once registered, up to 200 games may be played. 4) The door will display -= UNREGISTERED =- when returning to the BBS until you register. 5) You will receive preferential support from the author. 6) You will have peace of mind, knowing that you are supporting shareware. The key routine could probably be cracked eventually by someone with a hex editor and a lot of time on their hands. More elaborate protection schemes than mine have suffered this fate. However, I'm not asking much money for this -- so save yourself some effort and cough up the cash. How do you register? Send $10 (US) cash, check or money order, payable to Bruce Bowman, to the following address: DIRT CHEAP SOFTWARE c/o Bruce Bowman 8364 S. State Road 39 Clayton, IN 46118 Allow 2 weeks for personal checks to clear. I'm told it's not a good idea to send cash via the mail, but I've never had problems with it. If you decide to do so, and the money gets ripped off, I will feel sorry for you but I won't waive your registration fee over it. Accompany this with the form on the following page...or otherwise provide this information. Registrations without this information WILL be ignored (I will make a feeble attempt to contact you, and eventually tear up your check). It is also a very good idea to send a copy of your BBS drop file with your registration. Since the door reads data from your drop file to determine if the key will work, it is very important that both the sysop name and the BBS name be provided EXACTLY as present in your drop files. If you cannot guarantee this, you should send me your drop files. On occasion I have attempted to netmail certain individuals keys, only to get bad connects -- I simply cannot afford this. If your BBS is only online during certain hours, let me know. If I get two bad connects trying to netmail a key, I will give up and put it on hold for you and notify you of this fact via routed netmail (which itself is not very reliable anymore). NOTE: Registered keyholders receive FREE UPGRADES when they become available. You will have to check in though, since I don't plan to notify everyone of an upgrade individually. BCHECKERS REGISTRATION Version 1.3 IMPORTANT! The BBS name and SYSOP name must match your door IMPORTANT! IMPORTANT! drop file EXACTLY, or your key won't work. Consider IMPORTANT! IMPORTANT! sending us a copy of your BBS drop file(s)! IMPORTANT! *SYSOP NAME: __________________________________________________________ ADDRESS: ______________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ *BBS NAME: ____________________________________________________________ BBS Phone: ____________________________________________________________ BBS Software/Version: _________________________________________________ NETWORK: _______________________________________ (FidoNet, etc, if any) NETWORK NODE NUMBER: _______ : ________ / ________ (if above completed) AMOUNT ENCLOSED: ______________________ NOTE: Registration is $10! HOW DO YOU WANT TO PICK UP THE KEY? [ ] ... Put on hold for me at 1:231/710 for the Net/Node listed above. [ ] ... Send via FidoNet crashmail to the node indicated above. [ ] ... Here's $2.00 Upload it to me as well as the latest version. Acount Information as Follows: Account Name: Bruce Bowman Password: ____________________________________ Miscellaneous Info: ________________________________________ ____________________________________________________________ [ ] ... Send on disk to the address above (very slow!) Please add $5 to cover disk, mailing costs, and my hassle. Please ship my key and latest copy via [ ] - 5.25" [ ] - 3.5" [ ] ... YES!! I WANT THE SPECIAL DEAL! Send me latest version of KaBoom! and its key for only $5 more!! COMMENTS/SUGGESTIONS/BUGS: ____________________________________________ _______________________________________________________________________ __________________________________________________________________@o.th TECHNICAL SUPPORT ----------------- TECHNICAL SUPPORT IS PROVIDED ONLY THROUGH EMAIL OR CALLING MY BBS! I have had people ask me to call them long-distance on my dime -- I simply don't make enough money on BCheckers to justify this. There seems to be a perception amongst the sysop community that door authors are getting rich selling their doors, but the truth is that most sysops never register their doors. To provide some perspective, I've spent well over a hundred hours programming this door, and have yet to make $2/hour on it. To obtain support, you must call my BBS or send me email. You won't obtain full access to my BBS on your first call, but you can leave a message to the sysop at logoff, which I will get. You will then receive a temporary account until your problem is resolved. You'll have to call the BBS again to get your reply; or if you're on FidoNet and can wait, I can send you routed netmail. The H.O.M.E. BBS (317) 539-6579 - 28.8 kbps FIDONET: 1:231/710 DOORNET: 75:7317/71 INTERNET: beb@lilly.com or Bruce_Bowman@f710.n231.z1.fidonet.org If you are having problems with your key, you MUST give me a copy of your door drop files, or I won't be able to help you. FREQUENT COMMENTS ----------------- Q: The door can't find the game file, or it can't find my key even though I've registered. Help! A: Run the door from the directory containing the game file and the key. The executable can be anywhere on your path, and the drop file path is passed on the command line. If your key is named something else, be sure to rename it to BCHECK.KEY. The 52-line DOOR.SYS drop file does not contain the system name. Since the system name is necessary for the key routine to work, you must create some other drop file. I suggest you use one of the many drop file converters on the market; DoorMaster is probably the best program for this purpose. Make sure to configure the converter so it adds your BBS name to the new drop file. If your BBS software creates other drop files in addition to DOOR.SYS, try just adding DEL DOOR.SYS to the batch file before running the door. If it still does not recognize your key, you either did not provide the correct BBS and sysop names on your registration form, or your system is misconfigured so this information is not appearing in your drop files. Upload a copy of your drop files to the support BBS or via email to one of the listed addresses. Q: I know there's a game in there waiting for a new player, but the door won't let me make a move in that game. It doesn't even show up in the play list. A: Use the "join a game" function rather than "make a move." Q: The screen display gets messed up -- once it prints a move, the screen jumps up one line and subsequent prints overwrite the board. A: This happens only on the local screen when the status line is turned on. The remote screen is not affected. For local play, turn off the status line with F10 (it defaults to OFF anyway). I assume any local player already knows his own user stats. Q: The game prints [2;4m brackets and other junk characters all over. A: The door requires ANSI graphics capability. Exit the door and rectify the situation. Q: The status line function keys don't work right -- they cause the door to act peculiar and even lock up. A: Have you defined the offending F-keys to launch a macro? Don't feel bad; I did this myself with a DV script, and was quite bewildered for awhile! Q: The file BCHECK.BBS or BCHECK.HOF exists, but I occasionally still get a message from the door saying "Error opening BCHECK.BBS/BCHECK.HOF!" A: The door will try 20 times to open the file over a 10-second interval. If this fails, BCheckers gives up with an error. You may be running out of file handles. Increase the number of FILES in your CONFIG.SYS. It is also possible that one task in a multi-tasking environment opened the file, and then crashed without closing it. If so, you will probably have to reboot to clear the error. This may also rarely happen during intensive disk activity in a multi- tasking environment (for example, when copying files to/from floppies). Use a copy utility (like DVCOPY) that will properly release time slices to your door. You *do* have DOS's SHARE.EXE loaded, don't you? Q: The door gives me the error message -- "Timeout on BCHECK.BBS read operation." What does THAT mean? A: As before, a task has grabbed exclusive access to the file and never closed it (or at least didn't do so within 10 seconds). The remedy is pretty much the same; although if you were running the MAINT procedure during the error, the door will probably work now without rebooting. Q: BCheckers made me move somewhere I didn't want to move! A: The door enforces Hoyle's rules, and will not allow a caller to deviate from them. Since many of your callers will not be familiar with these rules, the key points are presented in the door help screens. PRODUCT HISTORY --------------- 1/81 Wrote my first Checkers game, in BASIC (of all things). Artificial intelligence -- play against the game. SLOW.... 3/94 Decided to write BCheckers, as an exercise in teaching myself C. Found out I could port almost *none* of my original BASIC code. 4/94 First beta release of BCheckers (version 0.90ß). Bug-laden. 6/94 Released version 1.0 (finally!). Fixed bug where the game always played in registered mode (boy, you guys would've loved that)! Apparently, fixing a drop file bug introduced another one. I believe I have it now... 6/94 Released version 1.0a. Version 1.0 was never really hatched, but a few people did file request it. While it's highly unlikely you will experience problems running 1.0, 1.0a does include more testing for file access conflicts in multi-node systems (and helpful error messages). Other minor cosmetic improvements (like stating that you are indeed being logged off when requested). 7/94 Released version 1.1 -- some minor bug fixes, as follows: 1) If more than 19 games, the <more> prompt is no longer displayed on the same line as the 19th game. 2) The "taken pieces" display would sometimes overwrite part of the "Checkers" logo if a player had crowned more pieces than his opponent had captured (a *very* rare circumstance). Fixed. 3) The game wouldn't recognize an upper case "Y" to verify a game forfeit (it would stubbornly wait for a lower case "y"). Fixed. 4) The color intensity on the remote screen would sometimes not be set properly. Fixed. New stuff: 1) Added the game-draw function. I have visions of many people out there playing version 1.0 with 1 king vs. 1 king, and no way to bring the game to a satisfactory conclusion! Shame on me... 2) Added the ability to set sysop paging hours. 3) Added support for leaving a note to your opponent. 4) Added the game status bulletin generator. 5) Added the hall of fame bulletin generator. 6) Added support for the RA 2.00 EXITINFO.BBS drop file format. 7) Logoff key is now "!". It was too easy to accidentally hit "9" rather than "8", and end up disconnecting rather than returning to the BBS. 7/94 Released version 1.1a. Found a minor bug in the Hall of Fame bulletin and squashed it. 8/94 Released version 1.2. Added a carriage return to the bulletin code in case the caller does not have screen clearing turned on. Changed all "Press any key" prompts to "Press ENTER." This allows the user to still take advantage of type-ahead, while fixing a problem with some modems sending a ^Q character when using XON/XOFF handshaking. Speeded up both the main menu and the board drawing routines. Board display now shows the player's names on both sides of the board. Some drop file converters pad the BBS name or sysop name with extra spaces, which caused difficulties in key recognition. BCheckers now strips these spaces prior to applying the key recognition routine. Made some minor changes in check for move legality in anticipation of a "play again the computer" mode for version 2.0. 8/94 I hate bug-fix releases! Version 1.2a was necessary to fix a bug that kept the bulletin generators from working. Also added code to flush the keyboard buffer just before exiting. 3/95 BCheckers 1.3 parses multiple drop files more effectively. This should solve some rare/intermittent problems with key recognition. The QuickBBS format of EXITINFO.BBS file is now handled properly. This should fix the "time left" problem on returning to QuickBBS. Previous versions of BCheckers required XON/XOFF handshaking if a FOSSIL was not available. Hardware handshaking is now supported. Non-standard IRQs and base addresses are now supported if not using a FOSSIL. Cleaned up the Hall of Fame code so that players with a 1-0 record aren't listed above those with a 10-0 record just because both are 100%. The "maxtime" parameter works now (when registered). FUTURE OF BCHECKERS ------------------- Ultimately, we may add internode or inter-BBS play. I've also had a request for a "play against the computer" mode, which I plan to implement in version 2.0. Register now while the program is still cheap! I would welcome other ideas on how BCheckers can be improved.